Setting up ResEdit EDL and VDL code for View Layouts
Containing Custom View Types
The "Plugin for ODF 1" file permits the localization of ODF parts containing most common ODF resoruce types, including standard view layout ('FWvl') resources. To install the plugin, just drag it to your ResEdit folder. If you're localizing parts created with ODF 2, use the "Plugin for ODF 2" file instead.
The plugin includes code written in two languages supported by ResEdit, the Exploder and Viewer Definition Languages (EDL and VDL). EDL describes the data model of a resource type, and VDL describes how a graphical editor for that resource type should be laid out. The code used to edit framework view layout ('FWvl') resources for localization relies on class labels stored within the resource data for information about how it should parse the resource into a series of editable fields. Support for class labels representing all standard ODF view types is included in the code; however, many developers will want to create their own custom view types derived from the standard types, and will use unique class labels to identify their types. To modify the plugin to support these changes, it's necessary to make changes to both the EDL and VDL code.
Modifying the EDL
In order to edit view layouts containing custom views with ResEdit, the 'FWvl' data model must first be modified to accomodate the new types. To do this, open the 'EDL ' resource named "Resource.FWvl" in the "Plugin for ODF" file. At the bottom of the EDL code is a Switch statement (shown here in condensed form):
Switch(fLabel)
{
.
.
.
case 'butn': {Call(FW_RButton);}
case 'popm': {Call(FW_RPopupMenu);}
case 'scbr': {Call(FW_RScrollBar);}
.
.
.
case 'edvw':
case 'Pwdv':
{
Call(FW_REditView);
}
case 'Sedv':
{
Call(FW_REditView);
Long(fHorizViewID);
Long(fVertViewID);
Long(fTextWidth);
}
case 'Frmv':
{
Call(FW_RPictSView);
Word(fPicture2);
List(fRadioClusters, RadioCluster, 3)
Call(FW_RRadioCluster); // list of 3 radio clusters
}
}
When one of the standard class labels ('butn', 'popm', etc.) is encountered, the EDL code calls a definition set up for that data type. If you add a custom type that doesn't add any new data fields to an existing type, you can just insert a case clause with your class label at the appropriate spot in the Switch. An example of this is shown with the 'Pwdv' type, above. 'Pwdv' represents a custom type used by the ODFForm example for a password field. It doesn't add any new data to the edit view ('edvw') class, so a new case label was just added that calls the same definition as that for the edit view class.
If you create a custom type that adds its own data fields to the resource type, you'll have to add a new case clause to the Switch. You can have the code in the new clause call the definition for the class from which you're deriving, and follow the call with statements representing your new data. Examples of this are shown above for the 'Sedv' (derived from FW_REditView) and 'Frmv' (derived from FW_RPictSView) classes. Some commonly-used statements you may want to use in your EDL code include:
Byte(fieldName); One-byte field
Word(fieldName); Two-byte field
Long(fieldName); Four-byte field
String(fieldName, LengthWord); String preceded by two bytes of length information
Data(fieldName, byteCount); byteCount bytes of data of unspecified format
PadByte(); Skip one byte
PadWord(); Skip two bytes
PadLong(); Skip four bytes
In addition, you can create lists of elements as follows:
List(fieldName, TypeName, numItems) List containing numItems elements
elements
List(fieldName, TypeName, OneBasedCount(16)) List preceded by a two-byte item count
elements
As an example, this code from the ODFRC definition for a radio cluster:
integer = $$CountOf(RadioArray);
array RadioArray
{
RadioID:
longint;
};
...is expressed in EDL as:
List(fRadioArray, RadioEntry, OneBasedCount(16))
Long(fRadioID);
Modifying the VDL
In order for ResEdit to support the editing of 'FWvl' resources containing your custom view layout, you need to make two changes to the VDL. First, open the 'VDL ' resource named "Resource.FWvl", and scroll down to the named statement called "ViewList":
This named statement is required as a workaround because of a problem placing a recursive "SELF" call in the default clause of a Switch in VDL. Just add a new case to the Switch containing the class label you selected for your class. This will enable ResEdit to recognize your custom view type.
Finally, scroll down to the bottom of the VDL code (where the main statement is):
Margin(2, 2, 2, 2)
Margin(5, 5, 5, 5, Single)
Switch(fLabel)
{
case 'root':
IncludeNamedStatement("FrameLayout");
.
.
.
case 'edvw':
case 'Pwdv':
IncludeNamedStatement("EditView");
case 'Sedv':
IncludeNamedStatement("ScrollingEditView");
.
.
.
If your new class doesn't contain any fields that need to be edited for localization beyond those in its parent class, you can just add a new case label in the appropriate place (as shown above for 'edvw' and 'Pwdv'). On the other hand, if you've added localizable data, you need to define a new named statement and add a new case clause that includes that named statement. You'll want to include the statement corresponding to the base class in your new statement, as shown below for the 'Sedv' class.
Most of the commands used in VDL are fairly self-explanatory: VList and HList allow the creation of nestable vertical and horizontal lists, Spacer leaves space in the layout, and EditText creates an editable text box corresponding to the resource field named in its first argument. For more information, please see the ResEdit documentation.
